The invention generally relates to computers and computer software and, in particular, to methods, apparatus, and computer program products for accessing content in a travel management system.
Content management systems can offer access to specific content to one or more clients (e.g., end consumers) connected to the system through dedicated communication networks. With the appearance of a huge number of content distribution providers in each industry area, there is a need for each consumer to be able to access multiple content providers through a unique content management system. For example, in the travel industry, travel management systems can be used to distribute content obtained from a set of travel provider systems (i.e., content providers) to a plurality of travel agency systems (i.e., content consumers).
The travel industry has grown significantly over the past decades. Over the same time period, the services provided by the travel industry have changed significantly such that many services involving heterogeneous content are now offered to end consumers. Further, the travel industry now involves a lot of players ranging from travel providers to end consumers and a huge amount of data that is to be managed among those players. Travel intermediaries, such as global distribution systems (GDS), between the travel provider and the end user provide travel management systems, which allow travel agents to retrieve information from traditional travel providers (e.g., airline providers) or to conduct transactions between end consumers and traditional travel providers.
With the attractiveness of such alternative distribution channels, travel agencies tend to distribute more and more non-GDS content (e.g., hotel, rental cars, etc.) aside from the usual GDS content (e.g., flight or rail content). However, conventional travel management systems cannot directly provide information to the travel agencies related to non-GDS content.
As shown in FIG. 1, a travel management system 1 generally comprises a record data structure, known as a passenger name record (PNR) 900, for storing records associated with GDS content directly received from GDS content providers 40. Each PNR 900 is identified in a database DB by a record locator. Record locators can then be used to access the GDS content and distribute it to client devices, such as travel agents or end consumers systems 60. Specifically, the PNR 900 may maintain a record locator linked with travel data associated with a given passenger or a group of passengers traveling together. The record locator is also known as a confirmation number, reservation number, confirmation code, booking reference, etc. For example, when a reservation is made for a passenger or group of passengers, a PNR is created in the data structure 900. This PNR includes a record locator and data corresponding to the reservation content (e.g., flight data such as arrival time, departure time, etc.).
Currently, travel management systems cannot directly receive non-GDS content from non-GDS travel providers 50 because of standardization constraints. Indeed, the way a travel management systems exchanges content with a standard travel provider 40 is subject to the rules defined by the International Air Transport Association (IATA) defined through the “ATA/IATA Reservations Interline Message Procedures—Passenger” (AIRIMP). Specifically, the messages exchanged between a standard travel provider 40 and the travel content management engine 30 must satisfy a message exchange format TTY (Teletype format) defined by IATA standard. Conventional PNRs 900 are configured to only handle content received in this TTY format.
An industry standard has not been defined as such for the layout and content of a PNR. However, each travel management system (e.g., computer reservation system or CRS) defines its own proprietary standards for the layout and content of the PNR taking into account the limitations of AIRIMP and, in particular, the need to map PNR data easily to AIRIMP messages. Accordingly, there exist many similarities with respect to the data content and format of PNRs maintained by different travel management systems. In particular, each PNR is such that the travel data associated with a record locator are to satisfy a number of predefined types that correspond to the GDS content standardized by IATA (flight data, rail data, etc.). Accordingly, only GDS content (e.g., flight, rail data) can be maintained in the data structure of the PNR 900 in a static format satisfying the constraints related to IATA message exchange standard. Hence, a record cannot be created for non-GDS content (car rental, jet ski, etc).
Conventional travel management systems 1 thus only handle content from GDS travel providers, such as airline providers. A conventional travel management system includes a travel content management engine 30 using many applications. Each application may be related to a specific travel service (e.g., booking, shopping, pricing, etc). In response to a request from a given travel agent (Ai) 70, the travel content management engine 30 can only retrieve content from GDS travel providers 40, generate a record in the PNR 900, and return a representation of the PNR record thus created to the travel agent Ai.
Each travel agent has to be directly connected to a set of non-GDS content providers 50 if the travel agent needs to access non-GDS content, while the travel management system 1 is only directly connected to GDS content providers 40. On the other hand, each travel agent is connected directly to a specific set of travel providers 50 to obtain non-GDS travel content (e.g., taxi, entertainment ticket, etc.). The travel content management engine 30 thus exposes n travel service platforms (one platform 2.1, 2.2, . . . 2.i, 2.n for each travel agent A1 to An), while handling only standard travel content (GDS content) from the standard travel providers 40.
Accordingly, if a given travel agent Ai wishes specific content from a non-standard travel provider 50 (e.g., museum ticketing), the content has to be self-implemented by the travel agent Ai. Such self-implementation is particularly costly and complex for the travel agents.
Further, in conventional approaches, the travel management system 100 stores the PNR content in a local format (source PNR content format). However, the travel management system may be required to exchange data from the PNR with other external systems (e.g., travel providers, travel agency) having their own format for PNR data (i.e., target PNR content format). Accordingly, depending on the target system, a conversion of the PNR content associated with a PNR record of the travel management system can be performed into the target PNR content format. Such conversion, which currently involves hard-coding and recompilation, is a costly and static approach. Similarly, in an application flow using PNR content inside the travel management system 100, each internal application in the application flow (i.e., chained application) that receives the PNR content is required to convert the PNR content in an application format in order to manipulate it. Each application in the chain is thus required to decode, validate, and encode the PNR content to be able to write or read it, which requires hand-coded components and may be costly.
Further, in a conventional travel management system, the PNR can be used by a huge number of applications currently configured to manipulate only standard types of content. Accordingly, to be able to manipulate new content types, it is currently required to recode all applications of the content management system, which may be costly.
There is accordingly a need for improved methods, apparatus, and computer program products for accessing content in a travel management system.